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Status of the Claims 

• Claims 1-8 are pending in the Application after entry of this amendment. 

• Claims 1-8 are rejected by Examiner. 

• No amendments are made to the claims. 

Claim Rejections Pursuant to 35 U.S.C. §102 

Claims 1-8 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
B. Carpenter, et al. Connection of IPv6 Domains via IPv4 Clouds (Network Working 
Group), hereafter referred to as "Carpenter" in view of US Patent Application 
Publication No. 2001/0040895 to Templin. Applicants respectfully traverse the 
rejection. 

The failure of an asserted combination to teach or suggest each and every 
feature of a claim remains fatal to an obviousness rejection under 35 U.S.C. § 103. 
Section 2143.03 of the MPEP requires the "consideration" of every claim feature in an 
obviousness determination. To render a claim unpatentable, however, the Office must 
do more than merely "consider" each and every feature for this claim. Instead, the 
asserted combination of the patents must also teach or suggest each and every claim 
feature. See In re Royka, 490 F.2d 981, 180 USPQ 580 (CCPA 1974) (emphasis added) 
(to establish prima facie obviousness of a claimed invention, all the claim features must 
be taught or suggested by the prior art). Indeed, as the Board of Patent Appeals and 
Interferences has confirmed, a proper obviousness determination requires that an 
Examiner make "a searching comparison of the claimed invention - including all its 
limitations - with the teaching of the prior art." See In re Wada and Murphy, Appeal 
2007-3733, citing In re Ochiai, 71 F.3d 1565, 1572 (Fed. Cir. 1995) (emphasis in 
original). "If an independent claim is nonobvious under 35 U.S.C. 103, then any claim 
depending therefrom is nonobvious" (MPEP §2143.03, citing In re Fine, 837 F.2d 
1071, 5 USPQ2d 1596 (Fed. Cir. 1988)). 
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Independent Claim 1 provides a method for supporting a 6to4 tunneling 
protocol across a network address translation mechanism. The method includes 
receiving, from a first host located on a first network, an outbound IPv6 packet 
encapsulated into an IPv4 packet. The IPv4 packet comprises a IPv4 header with a 
private IPv4 source address of the first host. The outbound IPv6 packet comprises a 
IPv6 header with a 6to4 source address and the IPv6 header comprising an Interface ID 
value. The private IPv4 source address in the IPv4 header is translated into a public 
IPv4 source address. The translated packet is transmitted over an IPv4 network to a 
remote host. The method further comprises storing an association of the private IPv4 
source address and the Interface ID value of the 6to4 source address for opposite 
address translation of inbound packets returned by the remote host. For the reasons 
presented below, it is respectfully submitted that Carpenter alone or in combination 
with Templin, fail to teach or suggest each feature of the present claimed arrangement. 



Carpenter describes, in Section 5.1, page 9, that "[w]hen an outgoing packet 
reaches the 6to4 router, it is encapsulated as defined in Section 3, according to the 
additional sending rule defined in Section 5.3. Incoming packets are decapsulated 
according to the additional decapsulation rule defined in Section 5.3." In Section 5.3 of 
Carpenter, decapsulation includes applying any security checks and removing the IPv4 
header and submitting the packet to local IPv6 routing. However, the decapsulation 
rules described in sections 5. 1 and 5.3 (and elsewhere) of Carpenter fail to teach or 
suggest "storing an association of the private IPv4 source address and the Interface ID 
value of the 6to4 source address for opposite address translation of inbound packets 
returned by the remote host" as in the present claimed arrangement. 

The Office Action acknowledges that Carpenter fails to teach or suggest 
"storing an association of the private IPv4 source address and the Interface ID value of 
the 6to4 source address for opposite address translation of inbound packets returned by 
the remote host" as recited in claim 1. However, the Office Action asserts that Templin 
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in paragraph 255, lines 1 - 6 discloses the present claimed feature. Applicants 
respectfully disagree. 

Templin describes a system facilitating IPv6-IPv4 compatibility wherein IPv6 
islands are present in heterogeneous IPv4/IPv6 networks (see para. [0005]). 
Specifically, in paragraph [0225], Templin describes a compatibility address format. 
Therein, Templin states that "[t]o communicate across the subnet 10 with the 
heterogeneous IP infrastructure, the IP host 12 and the gateway 16 use an aggregatable, 
global, unicast addresses". Templin defines these addresses as an "IPv6-IPv4 
compatibility address". The IPv6-IPv4 compatibility addresses enable IPv6 nodes to (1) 
forward IPv6 packets across native IPv6 routing infrastructure or (2) to automatically 
tunnel IPv6 packets over IPv4 routing infrastructure without requiring a pre-configured 
tunnel state. In Templin, a routing node 14 with an IPv6-IPv4 compatibility address can 
serve as a router for nodes 18 with native IPv6 addresses (i.e. IPv6 addresses that are 
not IPv6-IPv4 compatibility addresses) connected to the same link. In the instance 
where the node is a native IPv6 node, the IPv6-IPv4 routing node 14 can automatically 
tunnel messages across the IPv4 infrastructure of the subnet 10 to reach the gateway 
16. However, the IPv6-IPv4 compatibility addresses described in Templin is not 
equivalent to a "6to4 source address" that is included in the IPv6 header in the present 
claimed arrangement. Unlike Templin, the claimed method advantageously uses 6to4 
source addresses to facilitate communication between IPv6 sites or native IPv6 
networks over an IPv4 network without explicit tunnel setup (Specification, page 2, 
lines 18 - 22). Templin fails to teach or suggest the use of 6to4 source addresses and 
instead uses a compatibility address format that is not equivalent to the present claimed 
6to4 source addresses that are included within the IPv6 header in an outbound IPv6 
packet. 

Additionally, in paragraph [0251], Templin describes their mechanism for 
initiating a reverse network translation. Specifically, Templin describes transforming 
the IPv6-IPv4 compatibility address interface identifier 304 with embedded IPv4 
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address of the sending node into an anonymous ID for interdomain routing outside the 
subnet 10. Thus, the translation performed by Templin is done to prevent exposure of 
internal IPv4 addresses to domains outside the subnet. Templin, in paragraphs [0253] - 
[0255], further provides that the border gateway maintains a mapping identifier to the 
actual IPv4 address of the IPv4 node and that this identifier is not vulnerable to 
eavesdropping. However, this reverse network translation is described for globally 
unique IPv4 addresses which are not equivalent to the "private IPv4 source address" of 
the present claimed arrangement (see Templin, paragraphs [0242] and [0243] for the 
definition of globally unique IPv4 addresses). Moreover, in paragraphs [0258] - 
[0260], Templin provides that reverse network translation of non-globally unique IPv4 
addresses is not required except for potentially protecting against eavesdropping but is 
performed in the manner described above. Therefore, Templin merely stores an 
association of IPv4 source addresses that are not private address and an identifier that is 
not vulnerable to eavesdropping for reverse address translation of packets. The anti- 
eavesdropping identifier being associated with an IPv4 source address is not equivalent 
to "storing an association of the private IPv4 source address and the interface ID 
value of the 6to4 source address for opposite address translation of inbound packets 
returned by the remote host" as in the present claimed arrangement. Templin fails to 
teach or suggest using 6to4 addresses or an interface ID for a 6to4 address as in the 
present claimed method. 

The Office Action asserts it would be obvious to combine the features of 
Templin with the system of Carpenter to allow devices on an IPv6 network to send 
packets to and receive packets from devices on an IPv4 network. Applicants 
respectfully disagree. In fact, it is respectfully submitted that the system described by 
Templin is structurally and functionally incompatible with the system described by 
Carpenter and thus could not be readily combined to produce an operative system 
without frustrating the functionality of the individual systems. Specifically, Templin 
provides that IPv4 addresses within a subnet are private and are only transmitted in 
their current private form or, alternatively, replaced by an identifier that is not 
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vulnerable to eavesdropping (see Templin, para. [0260]). This is in direct contrast with 
Carpenter which describes any private IPv4 address is replaced by a public IPv4 
address in the IPv4 header prior to transmission of that packet. Thus, Templin teaches 
away from Carpenter because Templin fails to replace a private IPv4 source address 
with a public IPv4 source address and instead inserts an identifier to mask the private 
IPv4 address. Transmitting either the private IPv4 source address of an identifier for 
that source address as in Templin is not compatible with replacing a private IPv4 
source address with a public IPv4 source address as required by Carpenter. Therefore, 
one skilled in the art would not seek to combine these two systems to produce an 
operable system. 

Even if one were to combine the system of Templin with the system of 
Carpenter, the resulting system would neither teach nor suggest the features of the 
present claimed arrangement. The combination of Templin with Carpenter fails to 
enable opposite translation of inbound packets and support bidirectional 
communication in an X/Y NAT as stated on page 1 of the present specification. 
Specifically, Carpenter (with Templin) fails to teach or suggest "storing an association 
of the private IPv4 source address and the Interface ID value of the 6to4 source address 
for opposite address translation of inbound packets returned by the remote host" as 
recited in the claimed arrangement. Rather, the combined system would merely store an 
IPv4 source address and an identifier associated with that address that is not vulnerable 
to eavesdropping. Templin fails to teach or suggest the use of 6to4 addresses in any 
manner and thus cannot store the Interface ID value of the 6to4 source address. 
Furthermore, as acknowledged in the Office Action, Carpenter fails to teach or suggest 
the present claimed feature. Therefore, the combination of Templin with Carpenter fails 
to teach or suggest "storing an association of the private IPv4 source address and the 
Interface ID value of the 6to4 source address for opposite address translation of 
inbound packets returned by the remote host" as recited in claim 1. Consequently, 
withdrawal of the rejection of claim 1 is respectfully requested. 
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Claims 2 - 6 are dependent on claim 1 and are considered patentable for the 
reasons presented above with respect to claim 1 per MPEP §2143.03. Therefore, it is 
respectfully submitted that Carpenter (with Templin) fail to teach or suggest the 
features of claims 2-6. Consequently, withdrawal of the rejection of claims 2 - 6 is 
respectfully submitted. 

Independent claim 7 includes similar features as those described above with 
respect to claim 1. Therefore, Applicants respectfully submit that independent claim 7 
is patentable for the reasons presented above with respect to claim 1. Specifically, 
Carpenter (with Templin) fail to teach or suggest "an application for storing, for each 
outbound packet received from a host of an IPv6 network, the private IPv4 addresses 
and an Interface ID value included in a 6to4 source address of a host; and for updating 
a 6to4 destination address of an inbound packet with a stored private IPv4 address 
having same Interface ID as the 6to4 destination address" as recited in claim 7. 
Therefore, withdrawal of the rejection of claim 7 is respectfully requested. 

Claim 8 is dependent on claim 7 and is considered patentable for the reasons 
presented above with respect to claim 7per MPEP §2143.03. Therefore, it is 
respectfully submitted that Carpenter (with Templin) fail to teach or suggest the 
features of claim 8. Consequently, withdrawal of the rejection of claim 8 is respectfully 
submitted. 

In view of the above remarks, it is respectfully submitted that the Office Action 
fails to make a prima facie case that the present claimed arrangement is obvious over 
Carpenter alone or in combination with Templin. Therefore, as the combination fails to 
teach or suggest each feature claimed in claims 1 - 8, it is respectfully submitted that 
this rejection is overcome and should be withdrawn. 
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Conclusion 

Applicants respectfully submits that the pending claims patentably define over 
the cited art and respectfully requests reconsideration and withdrawal of the 35 U.S.C. 
§103 rejections of the pending claims. 

Having fully addressed the Examiner's rejections, it is believed that, in view of 
the preceding amendments and remarks, this application stands in condition for 
allowance. Accordingly then, reconsideration and allowance are respectfully solicited. 

No fee is believed due with this response. However, if there arc any additional 
charges in connection with this requested amendment, the Examiner is authorized to 
charge Deposit Account No. 07-0832 therefore. 



Respectfully submitted, 
Dirk Van Aken et al. 



Date: April 21, 2010 



/Jerome G. Schaefer/ 



Jerome G. Schaefer 
Attorney for Applicant 
Registration No. 50,800 
(609) 734-6451 
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